* Appl. No. 10/658,852 
Amendment & Response to Office Action of February 28, 2006 

REMARKS/ARGUMENTS 
Claims 1-14 and 22-30 are pending in the application. Claims 1, 8, 22 and 28-30 are the 

independent claims. 

I. Indication of Allowable Subject Matter 

Applicant thanks the Examiner for stating that Claims 4, 1 1 and 24 contain allowable 
subject matter and would be allowed if rewritten in independent form including all of the 
limitations of the base claim and intervening claims. As such, Applicant has added new Claims 
28, 29 and 30, corresponding to Claims 4, 11 and 24, respectively. Based on the Examiner's 
prior comments, it is submitted that new Claims 28-30 are allowable. 

II. Rejection of Claims 2, 8, 9 and 22 under 35 U.S.C. §112 

Claims 2, 8, 9 and 22 have been rejected under 35 U.S.C. §112, ^[2 because of insufficient 
antecedent basis for "the particular table" limitation in those claims. Those claims have been 
amended to more particularly point out and distinctly claim the invention. In view of these 
amendments, Applicant respectfully requests that the Examiner withdraw this rejection. 

III. Rejection of Claims 1-3, 5-6, 8-10, 12-13, 22-23 & 25-27 under 35 U.S.C. §102(e) 
On April 5, 2006, Applicant's attorney spoke with Examiner Truong on the telephone, 

where she indicated that she was withdrawing the rejection of Claims 1-3, 5-6, 8-10, 12-13, 22- 
23 and 25-27 under 35 U.S.C. § 102(e). As such, Applicant will not address that rejection at this 
time. Should Applicant have misunderstood Examiner Truong the rejection under § 102(e) 
is still outstanding), then Applicant requests that the Examiner please contact the Applicant 
immediately and Applicant will timely respond to that rejection. 

IV. Rejection of Claims 1, 8, and 22 under 35 U.S.C. §103 

Independent Claims 1, 8 and 22 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over U.S. Patent 6,122,640 to Pereira i^Pereira") in view of U.S. Patent 6,192,365 
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to Draper {"Draper"). Applicant respectfully submits that the Office Action fails to make out a 
prima facie case of obviousness. Specifically, the Office Action (1) failed to cite references that 
teach or suggest all of the elements recited in the rejected claims; (2) failed to show or cite where 
in the prior art there is a suggestion or motivation to combine the references; and (3) failed to 
show or cite where in the prior art there exists a reasonable expectation of success to combine 
reference teachings. 

Independent Claim 1, as amended, is similar to independent Claims 8 and 22, as 

amended, and reads as follows: 

"A method for obtaining and maintaining storage information related to storage 
characteristics of a table in a database, comprising: 

locking a particular table to be baselined; 

baselining the table contained in the database, wherein storage information 
comprising the average row length of the rows in the table and the average free space in 
the table is obtained; 

unlocking the table after it is baselined; 

making an entry into a transaction log, wherein the entry contains the storage 
information; 

retrieving the storage information from the transaction log; and 

periodically updating the storage information by monitoring subsequent entries in 
the transaction log." 

Contrary to the features recited by independent Claim 1, Pereira and Draper do not 
teach, hint, or suggest baselining a database table to obtain information related to storage 
characteristics (e.g., the average row length of the rows in the table and the average free space in 
the table) and then placing that storage information into a transaction log. Moreover, neither 
reference teaches retrieving storage information placed within the transaction log and then 
periodically updating the storage information by monitoring subsequent entries into the 
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transaction log. Because those two references - even in combination - fail to teach all of the 
claim limitations, the claims should be allowed. 
A. U.S. Patent 6,122,640 to Pereira 

Pereira teaches a method and apparatus for reorganizing a database management system 

("DBMS") table while the DBMS table remains available to users of the DBMS. Col 7, Ins. 7- 

77. Database tables are comprised of blocks and each block may contain multiple rows. Col. 1, 

Ins. 41-48. During creation of the table, the DBMS system will allocate enough contiguous 

blocks to meet the anticipated size of the table. Id. However, over the course of time, the 

database table may grow larger than anticipated, and the DBMS will allocate additional blocks as 

required. Col. 7, Ins. 59-63. Such additional blocks are typically not contiguous to the blocks 

initially comprising the table. This situation, among others, causes the database to become 

fragmented and operate inefficiently. Col 2, Ins. 36-38. When the database becomes 

fragmented, it is desirable to reorganize the table so that the table data can be retrieved more 

efficiently. Col 2, Ins. 48-52. Historically, a reorganization required the database to be taken 

"off-line," whereby the database was inaccessible to users. Col 3, Ins. 35-45. Using the method 

or apparatus of Pereira, however, the database tables remain available for all intended purposes 

throughout the reorganization process. Col. 3, Ins. 47-54. 

1. Pereira does not teach "baselining the table contained in the database, 
wherein storage information comprising the average row length of the 
rows in the table and the average free space in the table is obtained" 

Applicant respectfully submits that Pereira does not teach or suggest baselining a table to 

obtain storage information comprising the average row length of the rows in the table and the 

average free space in the table is obtained. Column 5, lines 40-45 of Pereira state: 

For example, in order to reorganize a database table, the structure of the database 
table must be known. A key element in the structure of an Oracle table is the 
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Oracle Row Address, also known as the "rowid." A rowid consists of a file 
number, block number and slot number. This uniquely defines and can be used to 
locate an Oracle row. 

When determining "the structure of a database table" for purposes of reorganizing a database 
table, however, it is not necessary to calculate statistical information like the average row length 
of the rows in the table or the average free space in the table. Rather, only information used to 
identify and locate a particular row, such as "file number, block number and slot number," is 
needed. 



Other portions of Perira, such as Table 5 and related text at column 10, lines 1-29, 
similarly do not teach or suggest baselining a table to obtain storage information comprising 
statistical information such as the average row length of the rows in the table and the average 
free space in the table. 



TABLE 5 



Dei^Tiptioft list* used during ifec ?corc process 
jifcicnj list Node in the Ust contains 

FilcNo Oracle f.totn FiJe Number 

IMocfc.No Starting Oracle Data Block 

Length No, of Block* in Ibis fcxtein 

Transaction Block List Node in tbe List contains 



HIcNo Oracle Dmn File Number 

BtockNo Oracle Block Number 

Count No. of transactions for ibis block 

Transaction list Node; in the list ooafeitas 

fowiil Oracle Row Address 

ivpe Transaction Type either I <*■ insert U * up date 

D-Dclete 

Delete And Insert list Node in the list contains 



SJotNo Slot where row is stored in an Crack* block 



As can be seen in the above table, Pereira teaches obtaining information for locating a particular 
block or row - like the Oracle data file number, the starting Oracle data block, the number of 
blocks in a particular extent, the number of transactions in a particular block, the Oracle row 
address, the transaction type and the slot where the row is stored in an Oracle block. Such 
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information is not equivalent to the average row length of the rows in the table or the average 
free space in the table. 

2. Pereira does not teach "making an entry into a transaction log, wherein 
the entry contains the storage information" 

Applicant also respectfully submits that Pereira does not teach entering storage 

information comprising statistical information such as the average row length of the rows in the 

table and the average free space in the table into a transaction log. Although Pereira does teach 

using "a trigger on a source table to record transactions into a transaction log table" at column 4, 

lines 15-17, recording "transactions" into a transaction log is not the same as recording the 

"storage information" obtained as a result of baselining a database table. The trigger in Pereira 

enters information about a particular transaction, "for example, rowid, type of transaction [T for 

insert, 'U' for update and 'D' for delete], and current time stamp." Col. 6 9 Ins. 57-61. That 

information is not storage information comprising statistical information such as the average row 

length of the rows in the table and the average free space in the table. Consequently, Pereira 

does not teach or suggest the step of "making an entry into a transaction log, wherein the entry 

contains the storage information," as required by the independent claims. 

3. Pereira does not teach "retrieving the storage information from the 
transaction log" 

Pereira also does not teach the step of retrieving storage information from a transaction 
log. As previously discussed, Pereira does not teach either baselining a table to obtain storage 
information or entering storage information into a transaction log. Consequently, Pereira cannot 
teach retrieving non-existent storage information that was never placed into a transaction log. 

This step is certainly not taught by Pereira at step 990 of Figure 9B. As can be seen from 
the figure below, deleting all the rows for a current block from a transaction log does not teach or 
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suggest retrieving storage information - deleting and retrieving are completely different 
operations and it is not necessary to retrieve information in order to delete that information. 

Delete from 
Transection Table all 
rows for current Block, 
Delete From Mapping 
Table all rows for 
current Block 

Furthermore, step 990 of Figure 9B requires deleting from the transaction table "all the rows for 

a current block :" it does not teach or suggest selectively retrieving "storage information" from a 

transaction log, as required by the independent claims. Therefore, Pereira does not teach the 

step of "retrieving the storage information from the transaction log." 

4. Pereira does not teach the step of "periodically updating the storage 
information by monitoring subsequent entries in the transaction log" 

The Examiner correctly noted that Pereira does not explicitly teach the step of 
"periodically updating the storage information by monitoring subsequent entries in the 
transaction log." Office Action of 2/28/06, p.8. Hence, Pereira fails to teach each of the steps of 
the independent claims. 

B. U.S. Patent 6 ,192,365 to Draper 

Draper relates to, among other things, a method of using a transaction log to synchronize 
multiple versions of a database residing on different computers. In the context of the Draper 
reference, a transaction log is a chronological record of operations that occur on a database. For 
example, if an object were added to a database, the transaction log associated with that database 
would be modified and an entry would be made into the transaction log reflecting that an object 
was added to the underlying database. Essentially, Draper teaches comparing the transaction 
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logs for two different versions of a database for inconsistencies and, in the event of an 

inconsistency, taking measures to resolve those inconsistencies. 

1. Draper does not teach "periodically updating the storage information by 
monitoring subsequent entries in the transaction log/ 5 

As part of an "accessing step," Draper teaches inserting an update history structure into a 
log database. Col. 36, Ins. 34-38. "The update history structure may be implemented using an 
unreplicated attribute of each log database object, an update tracking object in the log database, 
or other means. The update history structure is indexed on the UOID [Unique Object Identifier] 
of the target database object it refers to and contains as an attribute the UOID of the most recent 
previous update of the target database object in the log database." Col 36, Ins. 39-45. 

It is unclear from the above passage whether "the update history structure for transactions 
shows that the [Draper] system monitors transaction in the transaction log" (as the Examiner 
asserts at page 8 of the outstanding Office Action). However, it is certain that Draper does not 
teach periodically updating the storage information after monitoring subsequent entries in the 
transaction log. Draper does not teach or suggest the concept of "storage information 
comprising the average row length of the rows in the table and the average free space in the 
table." Rather, Draper teaches "a transaction log which represents a sequence of transactions in 
a network of connectable computers," whereby "each completed transaction in the transaction 
log has a corresponding transaction sequence number." Col. 2, Ins. 50-51; Col 3, Ins. 17-19. 
Such "sequence of transactions" and "transaction sequence number" do not constitute storage 
information comprising the average row length of the rows in the table and the average free 
space in the table. As Draper does not teach or suggest storage information, Draper cannot 
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teach monitoring subsequent entries in a transaction log and periodically updating the storage 
information. 

C. No Proper Suggestion or Motivation to Combine Pereira with Draper 

As detailed above, both Pereira and Draper, whether alone or taken in combination, fail 

to teach or suggest all the elements recited by independent Claims 1, 8 and 22. Moreover, the 

Office Action failed to show or cite where in the prior art there is a proper suggestion or 

motivation to combine the references. Section 2143 of the MPEP requires that the teaching or 

suggestion to combine references must be found in the prior art, not in the Applicant's 

disclosure. Section 2143 also states that the mere fact that references can be combined or 

modified does not render the resultant combination obvious unless the prior art also suggests the 

desirability of the combination. Finally, the MPEP notes that a statement that modifications of 

the prior art to meet the claimed invention would have been well within the ordinary skill of the 

art is not sufficient to establish a prima facie case of obviousness without some objective reason 

to combine the teaching of the references. That is, the level of skill in the art cannot be relied 

upon to provide the suggestion to combine references. 

The Office Action suggested that the motivation to combine Pereira with Draper would 

be "to improve the synchronization process or to maintain objects during making transactions in 

[a] transaction log." Office Action of 2/28/06, p. 12, For support, the Examiner apparently relies 

on an excerpt from Draper, 1 listed in pertinent part as follows: 

It is well-known in the database arts to maintain a log of transactions. However, 
conventional disconnectable systems are not traditional database systems. 
Conventional disconnectable systems lack transaction logs which can be used to 
identify and then modify or remove certain apparently inconsistent operations to 
improve the synchronization process. Conventional systems provide no way to 
compress transaction logs based on the semantics of the logged update operations. 

1 The Office Action found the motivation to combine the references in "col 2, lines 15-40." Applicant assumes that 
the Office Action refers to column 2, lines 15-40 of Draper. 
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Conventional systems also lack a way to use such transaction logs to recreate 
earlier versions of database objects. 

Thus, it would be an advancement in the art to provide a system and method for 
compressing a log of transactions performed on disconnectable computers. 

It would be a further advancement to provide such a system and method which are 
suited for use with systems and methods for transaction synchronization. 

That excerpt from Draper teaches a number of points, including: (1) it is desirable to combine 
conventional disconnectable systems with transaction logs that can be used to identify and then 
modify or remove certain inconsistent operations to improve the synchronization process, (2) it is 
desirable to compress transaction logs based on the semantics of the logged update operations, 
and (3) it is desirable to use transaction logs to recreate earlier versions of database objects. 
However, Draper does not teach or suggest "maintaining objects while making transactions in 
[a] transaction log," as the Examiner indicated. In addition, Draper does not teach or suggest 
that it would be obvious to combine (i) the method and apparatus for an online reorganization of 
a database management system table disclosed by Pereira with (ii) the method of using a 
transaction log to synchronize multiple versions of a database residing on different computers 
disclosed by Draper. There is no "synchronization process" in Pereira and thus a person of 
ordinary skill would not be motivated to combine Pereira with Draper in order to improve the 
non-existent synchronization process. 

The present invention requires the combination of at least two separate skills - (a) 
inserting and retrieving storage information comprising statistical information such as the 
average row length of the rows in the table and the average free space in the table from a 
transaction log and (b) periodically updating the storage information by monitoring subsequent 
entries in the transaction log. The present invention combines those two skills in a manner that is 



20 



Appl. No. 10/658,852 

Amendment & Response to Office Action of February 28, 2006 

not suggested by Pereira or Draper. In sum, since neither Pereira nor Draper include a 
suggestion or motivation to make the claimed invention, the Office Action has failed to make out 
a prima facie case of obviousness. Therefore, Applicant respectfully requests that the rejection 
of independent Claims 1, 8 and 22 be withdrawn. 

D. No Reasonable Expectation of Success if Pereira were combined with Draper 
Finally, as required by § 2143 of the MPEP, the Office Action failed to show or cite 
where in Pereira and Draper there exists a reasonable expectation of success if the reference 
teachings are combined. As pointed out above, Pereira teaches a method and apparatus for an 
online reorganization of a database management system table while Draper teaches a method of 
using a transaction log to synchronize multiple versions of a database residing on different 
computers. In short, the Pereira and Draper inventions are designed to solve completely 
different problems; online reorganization is completely different than synchronizing multiple 
versions of a database. Even assuming that there was a motivation to combine Pereira and 
Draper (which there is not), the Examiner has not shown that a person of ordinary skill in the art 
would reasonably expect the combination to succeed - a requirement for a prima facie case of 
obviousness. Therefore, Applicant respectfully requests that the rejection of independent Claims 
1, 8 and 22 be withdrawn. 

V. Rejection of Claims 2-3, 5-6, 9-10, 12-13, 23, and 25-27 under 35 ILS.C. §103 

The Examiner has also rejected dependent Claims 2-3, 5-6, 9-10, 12-13, 23, and 25-27 
under 35 U.S.C. 103(a) as being unpatentable over Pereira in view of Draper. However, for the 
same reasons as stated above with reference to the rejection of the independent claims, Applicant 
respectfully requests that the rejection of dependent Claims 2-3, 5-6, 9-10, 12-13, 23, and 25-27 
be withdrawn. More specifically, neither Pereira nor Draper: (1) teach or suggest all the 
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limitations of the independent claims from which Claims 2-3, 5-6, 9-10, 12-13, 23, and 25-27 
depend, (2) suggest a motivation to combine the references, or (3) demonstrate a reasonable 
expectation of success if the reference teachings are combined. 
VI. Rejection of Claims 7 and 14 under 35 U.S.C. §103 

Dependent Claims 7 and 14 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable (i) over Pereira in view of U.S. Patent 5,870,758 to Bamford ("Bamford") and (ii) 
over Pereira in view of Draper and further in view of Bamford. However, for the same reasons 
as stated above with reference to the rejection of the independent claims, Applicant respectfully 
requests that the rejection of dependent Claims 7 and 14 be withdrawn. More specifically, 
neither Pereira, Draper nor Bamford: (1) teach or suggest all the limitations of the independent 
claims from which Claims 7 & 14 depend, (2) suggest a motivation to combine the references, or 
(3) demonstrate a reasonable expectation of success if the reference teachings are combined. 
The Examiner did not cite Bamford as showing the claim limitations missing from either Pereira 
or the combination of Pereira and Draper. 

CONCLUSION 

Applicant believes this reply to be fully responsive to all outstanding issues and that the 
application, as amended by the foregoing claims, is in condition for allowance. Reconsideration 
of the application is respectfully requested. The Examiner is invited to contact the undersigned 
attorney at 713-758-2002 with any questions, comments or suggestions relating to the referenced 
patent application. 



22 



Appl. No. 10/658,852 

Amendment & Response to Office Action of February 28, 2006 



Respectfully submitted, 



VINSON & ELKINS L.L.P. 
Attorneys for Applicant 




Steve Borgman 
Reg. No. 33,160 
First City Tower 
1001 Fannin Street, Ste 2300 
j /oi / Houston, Texas 77002 

Date: ^t/^ r /0(p (713) 758-2002 
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